最常见的34个敏捷测试面试的Q&A(下)
昨天发布了 上半部分17个Q&A :最常见的34个敏捷测试面试的Q&A(上),今天再发布第18~34个Q&A。
18.统一过程(Rational Unified Process)和Scrum方法有什么区别?
RUP | SCRUM |
–正式的研发生命周期是由四个阶段构成,但是一些工作流可以是并发的 | –每个sprint都是一个完整的周期 |
–应用正式的项目计划,与迭代相关联 | –没有端到端的项目计划。下一个迭代计划都是在在当前迭代快结束时确定 |
–项目范围是在项目开始之前预先定义的,并在范围文档中记录。在项目中,范围可以被修改 | –使用的是项目待办事项列表(backlog),而不是范围scrum |
–产品(artifact)包括范围文档、正式的功能需求包、系统架构文档、开发计划、测试脚本等等 | –可运行的软件是唯一的正式产品 |
–推荐用于长期、大型、企业级的项目,具有中等程度以上的复杂性 | –推荐快速增强和不依赖于最后期限的组织 |
19. 为什么持续集成对敏捷很重要?
持续集成对于敏捷来说很重要,因为以下原因:
通过发现缺陷或集成错误,可以帮助保持及时发布产品。
由于频繁的敏捷代码交付,通常每个迭代(sprint)是2-3周,稳定的构建质量是必须的,并且持续集成确保做到这一点
帮助维护代码库的高质量状态(bug很少)
如果开发工作使用自动构建和合并功能,则持续集成有助于检查工作分支对主干的影响。
20. 在敏捷过程中进行了哪些测试?
在敏捷过程中,主要的测试活动是自动化单元测试和探索式测试。
但是,根据项目的需求,测试人员可以在被测应用(Application Under Test,AUT)上执行功能测试和非功能性测试。
(译者注:下面这图是落地的优秀实践 from 朱少民老师的演讲稿)
21.解释敏捷中的速度(Velocity)是什么?
速度是一种度量,是根据在迭代中所完成的用户故事相关的各种努力来估算出来的。它计算出在敏捷的一个迭代中可以完成多少工作,以及完成一个项目需要多少时间。
22. 优秀的敏捷测试人员应该具备哪些素质?
优秀的敏捷测试人员应该具备以下素质:
能够很快地理解需求
敏捷测试人员应该了解敏捷原则和概念
随着需求不断变化,测试人员应该了解其中的风险
基于需求,敏捷测试人员应该能够对工作进行优先级排序
业务伙伴、开发人员和测试人员之间的持续沟通是必须的
(译者注:你具备这些素质吗?😄)
23. 谁都参与了敏捷团队?
在敏捷中,两个主要的领导者是:
Scrum Master: 协调敏捷项目流程所需的绝大部分输入和输出
开发经理: 他们雇佣合适的人,并与团队一起培养他们。
24. 详细地描述Scrum Master 这个角色起什么作用?
Scrum Master的主要职责包括
了解需求并将其转换为可工作的软件
监控和跟踪
报告和沟通
过程检查大师
质量大师
克服障碍
解决冲突
保护团队和绩效反馈
领导所有会议,消除障碍
25. 提到敏捷的质量策略是什么?
敏捷质量策略是:
重构
非单一的(Non-solo)开发模式 (团队共同开发模式)
静态和动态代码分析
复审和审查
迭代(sprint)演示
全员(all hands)演示
轻量型的里程碑评审
短的反馈周期
标准和指导方针
26. 在开发敏捷项目时,屏幕截图工具,有什么推荐?
在开发敏捷项目时,您可以使用类似工具:
BugDigger
BugShooting
qTrace
Snagit
Bonfire
Usersnap
27. 在整个项目中保持一致的迭代周期,有什么好处?
好处是:
它帮助团队客观地衡量进展
它提供了一种测量团队速度的一致方法
它有助于建立一致的交付模式
28. 如果一个时间段计划的任务优先级需要再排序,谁应该做这件事?
如果一个时间段(time-box,可以看作一个迭代)计划需要重新排序(优先级排序),应该由整个团队、PO和开发人员来考虑。
29.提到燃尽图应该强调什么?
燃尽图显示了在时间段(迭代)结束之前需要完成的剩余工作。
30.提到Scrum和敏捷之间的区别是什么?
Scrum: 在Scrum中,sprint是开发的基本单位。每一个sprint后面都有一个计划会议,在这个会议中,sprint的任务被确定和估计。在每个sprint中,团队创建产品的部分功能特性
敏捷: 在敏捷中,每次迭代都涉及到一个团队,他们致力于完整的软件开发生命周期,包括计划、设计、编码、需求分析、单元测试,以及当向项目干系人演示产品时所做的的验收测试。
简而言之,敏捷是实践,scrum是遵循这一实践的过程。
(译者注:敏捷是方法论,Scrum是敏捷的实例化,即敏捷落地的具体流程、开发模式)
31.提到敏捷软件开发中所涉及的挑战是什么?
敏捷软件开发中涉及的挑战包括:
需要更多的测试和客户的参与 (译者注:测试不是减少了,而是增多了,包括TDD、对单元测试有更高的要求,国内不少人的认识是错误的)
对管理的影响超过了开发人员
每个特性都需要在移动到下一个迭代之前完成
所有代码都必须正常工作,以确保应用程序处于工作状态
需要更多的计划
【译者注:敏捷宣言强调拥抱变化胜于遵循计划,主要强调计划是一个过程(planning),而不是一个计划书文档,以后机械地遵守这个计划书。敏捷的计划并不少,从愿景、路线图(roadmap)到发布计划、迭代计划、每日计划。】
32.什么时候不使用敏捷?
在使用敏捷方法之前,您必须提出以下问题:
功能可以拆分吗?
客户在那里吗(客户可以和我们一起工作吗)?
需求很灵活吗?
时间限制真的很紧吗?
团队技能足够强吗?
(译者注:这就是我们经常说的“上下文”,敏捷有其更适应的环境 )
33. 解释你如何以一种简单的方式来实施scrum?
这些技巧可以帮助你在项目中实施scrum。
待办事项(backlog)(按对客户的价值)排好序
了解产品待办事项各项的大小
阐明sprint的需求和持续时间,以完成迭代backlog
估算团队sprint工作量,然后将需求分解为任务
协作工作区:一个所有团队讨论的中心,包括计划、路线图、关键日期、功能的草图、问题、日志、状态报告等等。
Sprint:确保在一段时间内完成一部分功能,然后继续下一个。除非没有其他选择,否则sprint不应该中止
参加每日的站立会议: 在会议上值得提一下,上次会议取得了什么成果?在下次会议前取得了什么成果?有没有阻碍我们前进的障碍?
使用燃尽图表来跟踪每天的进度。从燃尽图中,可以评估是在正常跑道上(正常状态)、还是在后面跑。
在进入下一个迭代之前完成每个特性;
在sprint结束的时候,召开一个sprint(迭代)回顾会议,展示sprint中的实现或交付。
34. 解释产品路线图是什么意思?
产品路线图是指创建产品远景的产品特性的整体视图。
参考
http://codesqueeze.com/how-to-be-a-tracer-bullet-architect/